Events

Information about events

Events sending

Client's application sends statements (events) to the engine in JSON format through HTTP connection (REST API). HTTP connection sends statements in packages. Data encryption is done using the SSL protocol.

Multiple sources

Data can come from multiple sources (users, game servers). Events are distinguished with a client_id variable. The application is customizable for specific customers through defining dedicated metadata (variables, aggregates, models).

Events processing order

Events processing order may not be maintained. It is determined on the basis of event time saved in JSON.

Transforming events to variables

Transform rules are defined in metadata as rules in JSONPath. Variables will be defined by analytics or generated automatically by analysis of given sample of events and verified by analytics.

Formats of JSONs containing events

Generic formats

For generic formats of JSONs, the Event Engine provides the most efficient processing.

Example of JSON:

{"arrival_ts":1232344,  
 "client_id":1, 
 "user_id":5, 
 "event_id":23,
"eventType1":
[
{"eventA":{"value":10, "name":"AAA"},
 "value":"value1"
},
{"eventB":{"value":45, "name":"BBB"},
 "value":"value2"       
}
               ]
            }

Examples of variable expressions

$.['eventType1'].[0].['eventA'].['value']

returns 10

$.['eventType1'].[1].['value']

returns "value1"

Examples of queries containing additional conditions

In generic format of JSONs, queries containing additional conditions are also optimized. These conditions can check equality by "==" sign and can be connected by "&&" sign.

$.['eventType1'].[0].['eventA'].[?(@.['value'] == 10 && @.['name'] == "AAA")].value

returns [10]

$.['eventType1'].[0].[?(@.['eventA'].['value'] == 10 && @.['eventA'].['name'] == "AAA")].value

returns "value1"

$.[?(@.name == 'eventType1')].['type'].[0].[?(@.event == 'eventA')].['value']

returns [10]

Other formats, compatible with JSONPath

These formats provides worse processing efficiency. An analytic must add rules defining the change from JSON format to a metadata variable (see chapter 5).

Example of JSON

{"arrival_ts":1232344,  
 "client_id":1, 
 "user_id":5, 
 "event_id":23,
 "name":"eventType1",
 "type":
    [
{"event":"eventA",
            "value":10
},
{"event":"eventB",
            "value":45
}
    ]
}

Example of variable expression

$.[?(@.name =~ /.*eve.*/i)].['type'].[1].['value']

returns [45]

Responses

A statement with score is a direct response to the bid request. The statement consists of scores for each impression:

• impid - id of the impression
• scores - a list of models and scores; empty, if none of models were scored or none of deployed models are active. Otherwise the list contains elements, where id of the model is a key and suggested bidding price is a value.

[
{
"impid": "424c6a8db16d4fa8ab853c5cd7b04ac7",
"scores": {
1314: 0.6930373068263596,
1315: 5.24522720421126,
1316: 44.87740531791001
}
},
{
"impid": "e5d26e91ac2441f997e3b1bee6168562",
"scores": {
1314: 0.6930373068263596,
1315: 5.24522720421126,
1316: 44.87740531791001
}
]

The price is calculated according to the formula:

min(10 * value, score * value * weight)

• score - scoring result
• value - value of a variable from models(CPC) table
• weight - weigh6t from models table (default 1000, because prices are bidded at the CPM rate)

Saving events

Every event is saved to a repository of events. If necessary, a backup of the repository can be made. Saving events do not block futher processing. The repository which stores events is made of txt files.